home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / satellit / pacdoc / uo22_img.doc < prev    next >
Text File  |  1992-08-31  |  11KB  |  212 lines
  1.  
  2. Image Header
  3.  
  4. The first 256 bytes in an IM file contain the Image Header. The format of this 
  5. header may change during experimentation, but it will always be a constant 256 
  6. bytes long. These bytes can either be discarded or interpreted according to 
  7. the following data structure:
  8.  
  9. struct CCDH_TAG {
  10.         time_t start_time;
  11.         time_t take_time;
  12.         unsigned long image_number;
  13.         unsigned long retries;
  14.         unsigned long set_image_num;
  15.         unsigned char integration;
  16.         unsigned char gain;
  17.         unsigned char unused[233];
  18.         unsigned char version;  
  19. } ccdh;
  20.  
  21. (Multi-byte values are stored least-significant byte first. time_t is four 
  22. bytes counting the number of seconds since 1/1/80. long is four bytes. char is 
  23. one byte. There are no slack bytes within the structure.)
  24.  
  25. start_time      is the scheduled time for the picture.
  26. take_time       is the time that the picture was actually taken.
  27. image_number    is the image number (as used in the IMxxxx file name).
  28. retries         currently unused, will be set by adaptive exposure software to 
  29.                 show how many images were discarded.
  30. set_image_num   not zero if command station was re-synchronising image 
  31.                 numbers.
  32. integration     zero is the longest integration, with increasing numbers 
  33.                 indicating shorter integration times. The range of 
  34.                 integration times is from 20 msec to 2 msec.
  35. gain            is two 4-bit numbers. The least-significant nibble sets the 
  36.                 low voltage threshold of the ADC, and the most significant 
  37.                 nibble sets the high voltage threshold. Between these two 
  38.                 thresholds 256 pixel values will be assigned. Changing the 
  39.                 values can expand or compress the camera's range to better 
  40.                 fit a particular scene.
  41. unused          is space reserved for future use
  42. version         is the last byte of the header. The current version is 0x80. 
  43.                 We will attempt to make future headers upwardly compatible 
  44.                 with version 0x80, by assigning meaning to currently 
  45.                 unused bytes. 
  46.  
  47. CCD Data 
  48.  
  49. Once the Image Header has been removed, only the CCD Data remains. This is the 
  50. contents of the CCD, stored as a sequence of horizontal scan lines. 
  51. Unfortunately, the CCD Data is not a simple raster image. Instead, it is 
  52. divided into three sections: the 288 even lines, followed by 355 bytes which 
  53. must be discarded, followed by the 288 odd lines. Each line is made up of 611 
  54. pixels.
  55.  
  56.         Line 0
  57.         Line 2
  58.         Line 4
  59.         ...
  60.         Line 574
  61.         Discard 355 bytes
  62.         Line 1
  63.         Line 3
  64.         ...
  65.         Line 575
  66.  
  67. When the image is displayed, the lines should be interleaved as follows, from 
  68. the top of the image:
  69.  
  70.         Line 0
  71.         Line 1
  72.         Line 2
  73.         ...
  74.         Line 575
  75.  
  76. With the lines interleaved correctly, the image can be treated as a two 
  77. dimensional array of 576 lines by 611 pixels. This is a raster image, which 
  78. can be displayed on your screen or used as input to further image processing 
  79. and format-changing programs.
  80.  
  81.  
  82. DISPLAYING UO-22 IMAGES
  83.  
  84. A relatively high quality graphics system is needed to display the entire UO-
  85. 22 CCD image. In particular, the system should display 64 or more shades of 
  86. grey. For MS-DOS users, this means at least a VGA adapter, and a Super VGA 
  87. with 800 X 600 X 256 is much better.  Mapping the image to fewer grey levels 
  88. will obscure the interesting detail in the pictures. Of course, it is best to 
  89. have the full image on the screen, but if you have to trade off resolution 
  90. against grey levels, go with the latter.
  91.  
  92. Users have taken two approaches to image display. Some have converted the 
  93. raster array to the standard Graphics Interchange Format (.GIF) and displayed 
  94. the image with public-domain, shareware or commercial GIF viewing programs. 
  95. Others have written their own programs to manipulate and display the raster 
  96. image. Each approach has advantages and disadvantages.
  97.  
  98. The .GIF format is popular, and .GIF viewers are available for most computers 
  99. - from Sun workstations to PCs. Once someone has converted one of UO-22's 
  100. images to .GIF format, the image can be widely distributed and viewed. GIF 
  101. copies of the best UO-22 images frequently show up on the UO-14 mailbox, 
  102. Compuserve, and the Internet. Some GIF viewers provide flexible contrast 
  103. control, stretching, and image enhancement. Unfortunately, others are 
  104. extremely simple and cope disappointingly with the wide dynamic range of the 
  105. UO-22 pictures. Some sources of shareware .GIF viewers and utilities are 
  106. listed at the end of this paper.
  107.  
  108. Writing your own display program is rewarding, but time consuming. It gives 
  109. you the best control over the finished image, allows you to get the most from 
  110. your particular computer and display, and educates you. The best current 
  111. example of this approach is DISPLAY4.EXE by Colin, VK5HI, which works on IBMs. 
  112. This program is distributed as freeware, and usually available on the UO-14 
  113. mailbox.
  114.  
  115.  
  116. INTERPRETING AND ENHANCING IMAGES
  117.  
  118. Once you have displayed an image, you have to interpret it. In some cases, 
  119. geographical features will be so stunning that identification will be obvious. 
  120. Usually, however, some contrast enhancement will be needed to bring your 
  121. display's 64 grey shades into the most interesting part of the picture, then 
  122. you have to get out a tracking program and an atlas to identify Earth 
  123. features. 
  124.  
  125. Some fixed features will become familiar to you as you experiment with UO-22 
  126. images. The two bands extending diagonally into the frame are the satellite's 
  127. antennas. If the image shows a large body of water, you may see the sun's 
  128. reflection making the water brighter than the land (a reversal of the normal 
  129. contrast). Sometimes (less and less frequently), you may see the limb of the 
  130. Earth, indicating that the UO-22 attitude control routines are out of tune. 
  131. Towards the edges of the picture - and particularly when these coincide with 
  132. the limb of the Earth - geographical  distortions become noticeable. Of 
  133. course, since UO-22 spins around its Earth-pointing axis, North won't always 
  134. be to the top of the image!
  135.  
  136. In general, picture quality is excellent, as shown by the photos accompanying 
  137. this paper. Contrast between land and sea is high, and the 2-km resolution can 
  138. be confirmed by examining coastlines and islands. Identifying scenes without 
  139. reference to satellite tracking software can stretch one's geographical 
  140. knowledge, but once the sub-satellite point and angle of rotation have been 
  141. determined, prominent features should be easily located with the aid of an 
  142. atlas.
  143.  
  144. After looking at raw images, you'll probably want to try some image 
  145. processing. If you write your own display program, you can implement your own 
  146. image processing algorithms and tightly integrate processing and display. If 
  147. you use the GIF route, you can still perform processing on the raster array 
  148. before conversion to GIF. In either case, your first job will be to get rid of 
  149. known anomalies in the UO-22 images.
  150.  
  151. Duplicated DASH Packets
  152.  
  153. For a combination of reasons, the communications protocol on the DASH link 
  154. sometimes duplicates packets between the Transputer and the 80C186 OBC. This 
  155. causes a 1-packet-long portion of the Image Header or CCD Data to be repeated. 
  156. On early images, these repeated sections were 254 bytes long; the packet 
  157. length was recently changed to 110 bytes. After removing the PACSAT File 
  158. Header, you can look for any 110-byte repeated blocks and remove them. (Be 
  159. careful not to throw out areas of uniform pixel value; if all the pixels in a 
  160. block have the same value, the block isn't a good candidate for removal.) 
  161. Fortunately, the repeated packet problem can be solved through modifications 
  162. to OBC and Transputer software. It is on the decrease, and shouldn't be with 
  163. us for much longer.
  164.  
  165. Pre-Image Slack
  166.  
  167. When the pixels are clocked from the CCD sensor into the image memory, some 
  168. initial non-image bytes are generated by the chip-set and stored by the DMA 
  169. hardware. If these bytes are not removed, they will show up at the beginning 
  170. of line 0; the end of line 0 will show up at the beginning of line 2, and so 
  171. on, down the image. Because this is a constant offset, the image will not be 
  172. distorted, but will appear to have "rolled" horizontally. Discarding 48 bytes 
  173. after the 256-byte header moves the image to the left hand side of the screen, 
  174. with all of the unused pixels showing up at the right hand end of each line.
  175.  
  176.  
  177. Pixel Dropout
  178.  
  179. Because a relatively slow, low-power ADC was used in the Camera Head, the ADC 
  180. cannot always follow the input video signal correctly. When the ADC cannot 
  181. keep up, invalid pixel values are stored in the image memory. These pixel 
  182. dropouts are usually on the right-hand edge of bright objects, and are either 
  183. very bright or very dark pixels. Pixel dropouts can be removed with a "median 
  184. filter" applied to each line. This filter examines a pixel, and if that pixel 
  185. is sufficiently different from its neighbours, sets the pixel to the median 
  186. value of its neighbors. For best results, the filter is applied from right to 
  187. left. It is worth experimenting with the threshold for droupout detection and 
  188. with schemes for identifying two immediately-adjacent dropouts.
  189.  
  190. The White Line
  191.  
  192. On all images produced by the UO-22 CCD camera,  two adjacent lines are 
  193. significantly brighter than their neighbours, creating a horizontal white line 
  194. across the image. A power surge in the CCD chip set during image capture 
  195. causes this. Roughly speaking, a constant value has been added to all of the 
  196. pixels in the line, and various schemes for removing this offset have been 
  197. attempted. First, locate the white lines by searching for a discontinuity in 
  198. the black reference band. Then calculate the average pixel value in each white 
  199. line and in the last preceding "normal" line. Finally, calculate the 
  200. difference between the "white line average" and the "normal line average" and 
  201. subtract this value from each pixel in the white line. This is not entirely 
  202. successful, but does reduce the impact of the horizontal stripe.
  203.  
  204. Low-Level Noise
  205.  
  206. It is inevitable that some noise creeps into the analogue signals as they are 
  207. amplified and sampled in the Camera Head. There are no simple filters to 
  208. eliminate this noise, which is only a bit or two in amplitude. Beware of this 
  209. noise when using extreme contrast enhancement, and when viewing images with 
  210. very low exposure. 
  211.  
  212.